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IANA Allocation Guidelines for the Protocol Field 
Status of This Memo 


This document specifies an Internet Best Current Practices for the 
Internet Community, and requests discussion and suggestions for 
improvements. Distribution of this memo is unlimited. 


Abstract 


This document revises the IANA guidelines for allocating new Protocol 
field values in IPv4 header. It modifies the rules specified in RFC 
2780 by removing the Expert Review option. The change will also 
affect the allocation of Next Header field values in IPv6. 


1. Introduction 


This document revises the IANA guidelines [RFC2780] for allocating 
new Protocol field values in IPv4 header [RFC0O791]. The change will 
also be applicable for IPv6, as the IANA guidelines for IPv6 Next 
Header values [RFC2460] allocation refer to the IPv4 guidelines. 


Previously, RFC 2780 allowed such allocations to happen through IESG 
Approval, Standards action, or Expert Review processes 

[RFC2780] [RFC2434]. The Expert Review process was specified to be 
used only in the case where a non-disclosure agreement was involved: 


TANA allocates values from the IPv4 Protocol name space following 
an Expert Review, IESG Approval or Standards Action process. The 
Expert Review process should only be used in those special cases 
where non-disclosure information is involved. In these cases the 
expert(s) should be designated by the IESG. 


The need for the Standards Action rule is obvious as the IETF keeps 
developing new protocols. It is equally obvious that there is a need 
to allow experimental allocations in this space; see RFC 4727 
[RFC4727] for an example. Similarly, there are cases when it makes 
sense to allocate values out of this space for other non-Standards 
Track or non-IETF uses. However, the size of the field is 256 
values, and 55% of these were in use at the time this document was 
written. As a result, a sanity check is needed to ensure that 
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allocations are not made needlessly. RFC 2780 specifies the IESG 
Approval rule to take care of these sanity checks for the non- 
Standards Track cases. The judgment call can take into account the 
existence of a stable protocol specification, constituency that wants 
to use it, need to avoid duplicated allocations for the same purpose, 
whether protocol number allocation is the right solution for this 
problem as opposed to, say, a TCP port, and so on. 


However, we now believe that the non-disclosure agreement option is 
not appropriate for allocations in this space. Traditionally, non- 
disclosure agreements have been used by the IANA when a company was 
developing a proprietary protocol and did not want to disclose new 
areas of research or future products. The protocol space is limited 
enough that we no longer believe that it is reasonable to use the 
resource for such proprietary protocols. Thus, we believe that 
allocations should only be made using the IESG Approval or Standards 
Action processes when there are public specifications that can be 
reviewed. 


As a result, this document revises the RFC 2780 rules by removing the 
option for Expert Review for the IPv4 Protocol and IPv6 Next Header 
fields. This document takes no position on the allocation of other 
parameters with non-disclosure agreements, as those parameters may 
require different policies. 


2. IANA Considerations 


This document replaces the RFC 2780 Section 4.3 rule [RFC2780] with 
the following: 


IANA allocates values from the IPv4 Protocol name space following 
an IESG Approval or Standards Action process. 


This document also makes an implicit change to the rule for the IPv6 
Next Header field in Section 5.3 of RFC 2780. That rule refers to 
the rule in Section 4.3 of the same RFC. From now on, this reference 
should be understood to refer to the rule revised here, i.e., without 
the Expert Review option. 


3. Security Considerations 


This specification does not change the security properties of the 
affected protocols. 
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Appendix A. Changes from RFC 2780 
Section 4.3 from RFC 2780 has been changed from: 


IANA allocates values from the IPv4 Protocol 
an Expert Review, IESG Approval or Standards 
Expert Review process should only be used in 
where non-disclosure information is involved. 
expert(s) should be designated by the IESG. 


to: 


IANA allocates values from the IPv4 Protocol 
an IESG Approval or Standards Action process. 


February 2008 


name space following 

Action process. The 

those special cases 
In these cases the 


name space following 


In addition, RFC 2780 Section 5.3 reference to IPv4 rules should be 


understood to refer to the rule revised here, i. 
Expert Review option. 
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